Using Risk to Balance Agile and Plan-Driven Methods

M ethodologies such as Extreme Programming (XP), Scrum, and agile software development promise increased customer satisfaction, lower defect rates, faster development times, and a solution to rapidly changing requirements. Plan-driven approaches such as Cleanroom, the Personal Software Process, or methods based on the Capability Maturity Model promise predictability , stability, and high assurance. However, both agile and planned approaches have situation-dependent shortcomings that, if left unaddressed, can lead to project failure. The challenge is to balance the two approaches to take advantage of their strengths in a given situation while compensating for their weaknesses. We present a risk-based approach for structuring projects to incorporate both agile and plan-driven approaches in proportion to a project's needs. We drew this material from our book, Balancing Agility and Discipline: A Guide for the Perplexed, to be published in 2003. Our method uses risk analysis and a unified process framework to tailor risk-based processes into an overall development strategy. This method enhances the ability of key development team members to understand their environment and organizational capabilities and to identify and collaborate with the project's stakeholders. We use risk analysis to define and address risks particularly associated with agile and plan-driven methods. The Risk-Based Spiral Model Anchor Points 2 provide the framework for this process. Both the Rational Unified Process 3 (RUP) and the Model-Based Architecting and Software Engineering (Mbase) process 4 have adopted these anchor points, which are essentially an integrated set of decision criteria for stakeholder commitment at specific points in the development process. Our method consists of five steps. Step 1 First, we apply risk analysis to specific risk areas associated with agile and plan-driven methods. We identify three specific risk categories: environmental , agile, and plan-driven. While not a simple task, Step 1 provides the basis for making decisions about the development strategy later in the process. If we uncover too much uncertainty about some risk categories, spending resources early to buy information about the project aspects that create the uncertainty may prove prudent. The candidate risks we describe are just that— candidates for consideration. They are neither complete nor always applicable, but serve as guides to stimulate participants' thinking. Next, we evaluate the risk analysis results to determine if the project at hand is appropriate for either purely agile or purely plan-driven methods. In these cases, the project characteristics fall squarely in the home ground of one approach or A …